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Abstract 


This document defines a set of enhancements to the Network News 
Transfer Protocol (NNTP) that allow a client to request extended 
information from NNTP servers regarding server status, policy, and 
other aspects of local configuration. These enhancements are made as 
new keywords to the existing LIST capability described in RFC 3977. 


This memo updates and formalizes the LIST DISTRIBUTIONS and LIST 
SUBSCRIPTIONS commands defined in RFC 2980. It also adds the LIST 
COUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies 
additional values returned by the existing LIST ACTIVE command for 
the status of a newsgroup. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6048. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
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include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The NNTP specification [RFC3977] defines the LIST capability anda 
few keywords that can be used with that command: ACTIVE, 
ACTIVE.TIMES, DISTRIB.PATS, HEADERS, NEWSGROUPS, and OVERVIEW.FMT. 
Other variants of the LIST command are in use, but with limited or 
absent documentation. These variants are formalized in this 
document. 


The DISTRIBUTIONS and SUBSCRIPTIONS variants were originally 
documented in [RFC2980]. The LIST DISTRIBUTIONS command is sent by a 
news client to obtain a list of relevant distributions known by a 
news server along with their descriptions. The LIST SUBSCRIPTIONS 
command is sent by a news client when first connecting to a news 
server so as to obtain a list of recommended newsgroups available on 
it. Both of these commands are intended to be used in place of hard- 
coding news clients to use specific distributions or look for 
specific default newsgroups. 


The MOTD variant was originally documented in [NNTP_LIST] (which also 
describes the SUBSCRIPTIONS variant). The LIST MOTD command is sent 
by a news client to obtain a "message of the day" from the server 
administrator regarding the current state of a news server. 


The COUNTS and MODERATORS variants have not been documented before. 
The LIST COUNTS command is similar to LIST ACTIVE, except that it 
also returns an estimated number of articles in each newsgroup. The 
LIST MODERATORS command is sent by a news client to obtain a list of 
associations between a moderated newsgroup and its submission address 
template. 


The ACTIVE variant was formalized in [RFC3977], but the meanings of 
only three status field values in LIST ACTIVE responses have been 
specified: "y", "n", and "m". These statuses are particularly useful 
for readers, since they describe local posting rights. However, 
several other statuses are in use that are primarily useful for peers 
as they mainly describe how remote articles coming from peers are 
locally handled by a given news server. This memo defines three 
other values for the status field in LIST ACTIVE responses: "x", "j", 
and "=" followed by the name of a newsgroup. 


This specification should be read in conjunction with the NNTP base 
specification [RFC3977]. In the case of a conflict between these two 
documents, [RFC3977] takes precedence. 
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1. Conventions Used in This Document 


The notational conventions used in this document are the same as 
those in [RFC3977], and any term not defined in this document has the 
same meaning as it does in that one. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


When a hexadecimal correspondence is given to an octet in this 
document, the value is in US-ASCII [ASCII] (for instance, ".", noted 
%x2E). 


In the examples, commands from the client are indicated with [C], and 
responses from the server are indicated with [S]. The client is the 
initiator of the NNTP connection; the server is the other endpoint. 


.2. Author's Note 


Please write the first letter of "Elie" with an acute accent wherever 
possible -- it is U+00C9, that is to say "&#201;" in XML. 


New LIST Variants 
The LIST capability is defined in Section 7.6 of [RFC3977]. It 
allows the server to provide useful information to the client in 


multi-line blocks. 


This document provides five new keywords to the LIST capability: 
COUNTS, DISTRIBUTIONS, MODERATORS, MOTD, and SUBSCRIPTIONS. 


Each keyword is OPTIONAL and corresponds to the same-named variant of 
the LIST command. 


1. Advertising the New LIST Variants 


When a news server implements a variant of the LIST command as 
described in this specification, it advertises the corresponding 
feature in the LIST capability. Where one of these new LIST keywords 
is advertised, it MUST have the meaning given in this specification. 


For instance, if a news server implements the SUBSCRIPTIONS variant, 
it will add the SUBSCRIPTIONS keyword to the LIST capability in 
response to the CAPABILITIES command (see Section 5.2 of [RFC3977]): 
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[C] CAPABILITIES 
[S] 101 Capability list: 
[S] VERSION 2 


[S] READER 
[S] LIST ACTIVE NEWSGROUPS SUBSCRIPTIONS 
[S] 


[C] LIST SUBSCRIPTIONS 

[S] 215 List of recommended newsgroups follows 
[S] local.welcome 

[S] local.test 

[S] news.newusers.questions 

[S] news.announce.newusers 


[S] 


For each of the new LIST variants described in this specification, an 
empty response can be sent to the client: 


[C] LIST SUBSCRIPTIONS 
[S] 215 List of recommended newsgroups follows 
[S] 


This means that the information is maintained by the news server but 
that it is voluntarily empty. Frequently, the news server maintains 
the information in a configuration file. This file can be empty or 
contain only commented or blank lines, indicating a voluntary absence 
of information. 


When the news server software implements one of these LIST variants 
but a particular server does not maintain the information (for 


instance, when the configuration file does not exist), the 503 
response code MUST be returned: 


[C] LIST SUBSCRIPTIONS 
[S] 503 No list of recommended newsgroups available 


2.2. LIST COUNTS 
2.2.1. Usage 


Syntax 
LIST COUNTS [wildmat] 


Responses 

215 List of newsgroups follows (multi-line) 
Parameters 

wildmat Groups of interest 
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2.2.2. Description 


See Section 7.6.1 of [RFC3977] for general requirements of the LIST 
command. 


The LIST COUNTS command returns a list of valid newsgroups carried by 
the news server along with associated information, the "counts list", 
and is similar to LIST ACTIVE. 


The information is returned as a multi-line data block following the 
215 response code and contains one line per newsgroup. Each line of 
this list MUST consist of five fields separated from each other by 
one or more spaces (the usual practice is a single space) in the 
following order: 


o The name of the newsgroup. 

o The reported high water mark for the group. 

o The reported low water mark for the group. 

o The estimated number of articles in the group. 
o The current status of the group on this server. 


The reported high and low water marks, and the estimated number of 
articles, are as described in the GROUP command (see Section 6.1.1 of 
[RFC3977]), but note that they are in the opposite order to the 211 
response (that is, number low high group) to the GROUP command. The 
current status of the group is as described in the LIST ACTIVE 
command (see Section 7.6.3 of [RFC3977], as well as Section 3 of this 
document). Also note that, similarly to the LIST ACTIVE command, TAB 
characters are not valid separators for the LIST COUNTS command. 


The order of newsgroups in the counts list is not significant. The 
server need not consistently return the same order or the same 
results if this command is used more than once in a session. 


The same newsgroup SHOULD NOT appear twice in the output of this 
command. 


The counts list is newsgroup-based, and a wildmat MAY be specified, 
in which case the response is limited to only the groups, if any, 
whose names match the wildmat. If no wildmat is specified, the 
server MUST include every newsgroup that the client is permitted to 
select with the GROUP command (see Section 6.1.1 of [RFC3977]). 
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The counts list MAY be empty. If the server does not maintain the 
information, a 503 response code MUST be returned. (However, note 
that a news server that supports this command usually maintains the 
information.) 


The client MAY use LIST COUNTS in order to obtain an estimate of the 
number of articles in every newsgroup the server carries, which 
enables it to provide the end user with this information. This 
provides a simpler mechanism for a client to obtain the estimated 
number of articles in newsgroups, compared with a sequence of 
individual GROUP commands. 


2.2.3. Examples 
Example of output with no argument: 
[C] CAPABILITIES 


[S] 101 Capability list: 
[S] VERSION 2 


[S] READER 
[S] LIST ACTIVE COUNTS NEWSGROUPS 
[S] 


[C] LIST COUNTS 

[S] 215 List of newsgroups follows 
[S] misc.test 3002322 3000234 1234 y 
[S] comp.risks 442001 441099 742 m 
[S] rec.food.drink.tea 100 51 3 y 
[S] local.empty 7 8 0 y 

[S] local.tea 2004 1504 301 y 

[S] 


Example of output with a wildmat: 


[C] LIST COUNTS *.tea,misc.*,!local.* 
[S] 215 List of newsgroups follows 
[S] misc.test 3002322 3000234 1234 y 
[S] rec.food.drink.tea 100 51 3 y 

[S] 


Elie Standards Track [Page 7] 


RFC 6048 NNTP Additions to LIST Command November 2010 


Example of output on an implementation that includes leading zeroes: 


[C] LIST COUNTS 

[S] 215 List of newsgroups follows 

[S] misc.test 0003002322 0003000234 1234 y 

[S] comp.risks 0000442001 0000441099 742 m 

[S] rec.food.drink.tea 0000000100 0000000051 3 y 
[S] local.empty 0000000007 0000000008 0 y 

[S] local.tea 0000002004 0000001504 301 y 

[S] . 


The estimated number of articles usually does not start with leading 
zeroes, but MAY start with such zeroes. 


Ze Ses LIST DISTRIBUTIONS 
2.3.1. Usage 


Syntax 
LIST DISTRIBUTIONS 


Responses 
215 Distributions list follows (multi-line) 


2.3.2. Description 


See Section 7.6.1 of [RFC3977] for general requirements of the LIST 
command. 


A "distributions list" is maintained by some NNTP servers to contain 
the name of each distribution that is known by the news server and a 
short description about the meaning of the distribution. 
Distributions are used by clients as potential values for the 
Distribution header field body of a news article being posted (see 
Section 3.2.4 of [RFC5536] for the definition of this header field). 


The information is returned as a multi-line data block following the 
215 response code and contains one line per distribution. Each line 
of this list MUST consist of two fields separated from each other by 
one or more space or TAB characters (the usual practice is a single 
TAB). The first field is the name of the distribution, and the 
second field is a short description of the distribution. There are 
no leading or trailing whitespaces in a line. The description MAY 
contain whitespaces. 
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The order of distributions in the distributions list is not 
significant; the server need not consistently return the same order 
or the same results if this command is used more than once ina 
session. 


The same distribution SHOULD NOT appear twice in the output of this 
command. 


The description MUST be in UTF-8 [RFC3629]. 


The distributions list is not newsgroup-based, and an argument MUST 
NOT be specified. Otherwise, a 501 response code MUST be returned. 


The distributions list MAY be empty. If the server does not maintain 
the information, a 503 response code MUST be returned. 


The client MAY use this information to generate or supplement a list 
of known distributions provided to the user. If the news server 
implements the LIST DISTRIBUTIONS command, it SHOULD also implement 
the LIST DISTRIB.PATS command (defined in Section 7.6.5 of [RFC3977]) 
and describe in the distributions list all the distributions present 
in the distrib.pats list so that the client can use both of these 
commands jointly (naturally, the distributions list can also describe 


distributions that are not present in the distrib.pats list). Note 
that the two commands need not return distributions in the same 
order. 
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2.3.3. Example 
Example of a joint use of LIST DISTRIB.PATS and LIST DISTRIBUTIONS: 
[C] CAPABILITIES 


[S] 101 Capability list: 
[S] VERSION 2 


[S] READER 
[S] LIST ACTIVE DISTRIB.PATS DISTRIBUTIONS NEWSGROUPS 
[S] 


[C] LIST DISTRIB.PATS 

[S] 215 Information follows 

[S] 10:local.*:local 

[S] 5:france.*:fr 

[S] 20:local.here.*:thissite 

ES] . 

[C] LIST DISTRIBUTIONS 

[S] 215 List of distributions follows 
[S] fr Local to France. 

[S] local Local to this news server. 
[S] thissite Local to this site. 

[S] usa Local to the United States of America. 
[S] 


2.4. LIST MODERATORS 
2.4.1. Usage 


Syntax 
LIST MODERATORS 


Responses 
215 Moderators list follows (multi-line) 


2.4.2. Description 


See Section 7.6.1 of [RFC3977] for general requirements of the LIST 
command. 


The "moderators list" is maintained by some NNTP servers to make 
clients aware of how the news server will generate a submission 
e-mail address when an article is locally posted to a moderated 
newsgroup. 


The information is returned as a multi-line data block following the 
215 response code. Each line of this list MUST consist of two fields 
separated from each other by a colon (":" or %x3A). The first field 
is a wildmat (which may be a simple newsgroup name), and the second 
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field is the submission address template for newsgroups matching that 
wildmat. There are no leading or trailing whitespaces in a line. 
The submission template MAY contain colons (":"). 


The submission template is essentially an e-mail address (see the 
definition of "addr-spec" in Section 3.4.1 of [RFC5322]), except with 
certain modifications. The case-sensitive string "%s" (%x25.73) MUST 
occur either zero or one time in the template. If there is to be a 
literal "%" in the submission address, it MUST be written as "%%" in 
the template, even if not followed by an "s". The character "%" MUST 
NOT occur in the submission template, except as part of "Ss" or "SS". 


The order of lines in the moderators list is significant: the first 
matching line is used. Consequently, specific patterns should be 
listed before general patterns. Every moderated newsgroup name 
SHOULD be matched by at least one line in the list; often this is 
achieved by having a default pattern at the bottom, but other 
approaches are acceptable, and news server software MAY leave this up 
to the server administrator rather than enforcing it 
programmatically. 


When an article without an Approved header field is locally posted to 
a moderated newsgroup, the server generates a submission address from 
the corresponding submission template (that is, the second field of 
the first matching line in the moderators list) by replacing the 
"Ss", if present, with the name of the matching newsgroup after each 


period ("." or %x2E) in the name has been changed to a dash ("-" or 
%x2D). In addition, any "%%" is changed back to "%". The server 


then forwards the submitted article to the moderator at the resulting 
submission address (see Section 3.5.1 of [RFC5537]). 


NOTE: The creation and maintenance of submission addresses is 
outside the scope of this specification. 


The moderators list is not newsgroup-based, and an argument MUST NOT 
be specified. Otherwise, a 501 response code MUST be returned. 


The moderators list MAY be empty. If the server does not maintain 
the information, a 503 response code MUST be returned, although these 
situations should not occur if the news server is an injecting agent 
that carries moderated newsgroups. 
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2.4. 


Example 


Example of output: 


[C] CAPABILITIES 

[S] 101 Capability list: 

[S] VERSION 2 

[S] READER 

[S] POST 

[S] LIST ACTIVE MODERATORS NEWSGROUPS 
ES = 

[C] LIST MODERATORS 

[S] 215 List of submission address templates follows 
[S] foo.bar:announce@example.com 

[S] local.*:%s@localhost 

[S] *:%s@moderators.example.com 

[S] 


The following table describes a few examples associating a moderated 
newsgroup and its submission address on a news server whose 
moderators list is the one in the previous example: 


+ on ef ay a ee Oy a ee ae 
Name of the moderated 
newsgroup 


Elie 


foo.bar 
local.test local-test@localhost 

alt.dev.null alt-dev-null@moderators.example.com 
alt.test-—me | 

e Se A a E S E + 


——— — — — — + 
Submission address | 


——— — — — + 
announce@example.com | 


—+—— + 


alt-test-me@moderators.example.com_ | 


NOTE: When "Ss" is used, periods are changed to dashes, and dashes 
are left alone. This implies that two moderated newsgroups whose 
names differ only by changing a period to a dash would have the 
same submission address. Therefore, if a server carries such 
moderated newsgroup pairs but posts should go to different 
submission addresses, a "Ss" pattern template cannot be used for 
the moderation submission addresses for those groups, and explicit 
entries without a pattern will be required. 


Similarly, it is not recommended to use a "%s" pattern rule for 
the moderation submission template for two moderated newsgroups 
whose names differ only by the case of their characters, because 
e-mail systems frequently treat the left-hand side of e-mail 
addresses as case-sensitive. See also Section 3.1.4 of [RFC5536] 
and Section 7.2 of [USEAGE] for the syntax of a newsgroup name. 
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Divides LIST MOTD 
2.5.1. Usage 


Syntax 
LIST MOTD 


Responses 
215 Information follows (multi-line) 


2.5.2. Description 


See Section 7.6.1 of [RFC3977] for general requirements of the LIST 
command. 


The "motd" contains a "message of the day" relevant to the news 
server. It is intended to provide notification and communication 
between the news administrator and the news user. For instance, 
notification of upcoming downtime or information about new facilities 
available on the news server can be communicated via the LIST MOTD 
command. 


The information is returned as a multi-line data block following the 
215 response code. This text is not guaranteed to be in any 
particular format although, like all multi-line data blocks, it is 
"dot-stuffed". 


The server need not return the same information if this command is 
used more than once in a session. It MAY indeed send a different 
message of the day depending on the state of the session. For 
instance, on a mode-switching news server, the information can be 
different between its transit mode and its reader mode, or between an 
authenticated session and an unauthenticated session. 


The information MUST be in UTF-8 [RFC3629]. 


The motd is not newsgroup-based, and an argument MUST NOT be 
specified. Otherwise, a 501 response code MUST be returned. 


The motd MAY be empty. If the server does not maintain the 
information, a 503 response code MUST be returned. 


It is up to the client to decide when and how to display this message 
to the user. No timestamp or date of last modification is provided 
programmatically, although the news administrator may include one in 
the text of the motd. The client MAY cache a local copy or 
fingerprint of the motd so that it can display the message to the 
user only upon modification. If the client caches the information, 
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2. 


it MAY take into account only the motd obtained after reaching the 
intended state of the session. Nonetheless, in case a privacy 
extension is used, the client MUST NOT cache any motd obtained before 
that extension took effect. 


NOTE: Though the client MAY cache the results of this command, it 
MUST NOT rely on the correctness of any cached results, whether 
from earlier in the session or from a previous session. If the 
motd is cached, the client SHOULD provide a way to force the 
cached information to be refreshed. 


5.3. Example 
Example of output: 
[C] CAPABILITIES 


[S] 101 Capability list: 
[S] VERSION 2 


[S] READER 
[S] LIST ACTIVE MOTD NEWSGROUPS 
[S] 


[C] LIST MOTD 

[S] 215 Message of the day follows 

[S] Attention all users, 

[S] 

[S] This server will be down for scheduled upgrades on February ist. 
[S] It should be back up by 8:00 a.m. February 2nd. 

[S] Any questions should be e-mailed to <newsmaster@example.com>. 
[S] 

[S] Apologies for the disturbance. 

[S] 


-6. LIST SUBSCRIPTIONS 


-6.1. Usage 


Syntax 
LIST SUBSCRIPTIONS [wildmat] 


Responses 

215 Subscriptions list follows (multi-line) 
Parameters 

wildmat Groups of interest 
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2.6.2. Description 


See Section 7.6.1 of [RFC3977] for general requirements of the LIST 
command. 


The "subscriptions list" is maintained by some NNTP servers to 
provide the client with a list of recommended newsgroups. 


The information is returned as a multi-line data block following the 
215 response code. Each line of this list MUST consist of a 
newsgroup name. There are no leading or trailing whitespaces ina 
line. 


The order of newsgroups in the subscriptions list is significant: 
they are listed by order of importance, the first newsgroup being the 
most important to subscribe to. 


The same newsgroup name SHOULD NOT appear twice in the output of this 
command. The subscriptions list SHOULD contain only newsgroups the 
news server carries. 


The subscriptions list is newsgroup-based, and a wildmat MAY be 
specified, in which case the response is limited to only the groups, 
if any, whose names match the wildmat. Note that the wildmat 
argument is a new feature in this specification, and servers that do 
not support CAPABILITIES or do not advertise the SUBSCRIPTIONS 
keyword in the LIST capability (and therefore do not conform to this 
specification) are unlikely to support it. 


The subscriptions list MAY be empty. If the server does not maintain 
the information, a 503 response code MUST be returned. 


The client MAY use this information the first time it connects to the 
news server so as to initialize the list of default subscribed 
newsgroups. This list should therefore contain groups intended for 
new users on the news server or Usenet in general (for instance, 
newsgroups dedicated to testing, support, announcement, or FAQs). 

The client MAY present the groups in the order of appearance in the 
list to the user. When the subscriptions list is maintained and 
non-empty, the news client SHOULD use it, instead of a hard-coded 
default list, if any. 
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2.6.3. Examples 


Example of output with no argument: 


[C] 
[S] 
[S] 
[S] 
[S] 
[S] 
[C] 
[S] 
[S] 
[S] 
[S] 
[S] 
[S] 


CAPABILITIES 

101 Capability list: 

VERSION 2 

READER 

LIST ACTIVE NEWSGROUPS SUBSCRIPTIONS 


LIST SUBSCRIPTIONS 

215 List of recommended newsgroups follows 
local.welcome 

local.test 

news .newusers.questions 
news.announce.newusers 


Example of output with a wildmat: 


[C] 
[S] 
[S] 
[S] 
[S] 


LIST SUBSCRIPTIONS local.* 

215 List of recommended newsgroups follows 
local.welcome 

local.test 


3. Additions to LIST ACTIVE 


November 2010 


This document specifies three new status field values that can be 


used in the answers to LIST ACTIVE: "x", "j", and 


name of a newsgroup. 


3.1. New Status Field Values 


The LIST ACTIVE command is defined in 
The fourth field of each line of this 
status of the newsgroup whose name is 
Three status field values are defined 


"y" Posting is permitted. 


"n" Posting is not permitted. 


"=" followed by the 


Section 7.6.3 of [RFC3977]. 
list indicates the current 
specified in the first field. 
in [RFC3977]: 


"m" Postings will be forwarded to the newsgroup moderator. 


Elie 
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This document defines three other case-sensitive status field values 
that can also be used: 

"x" Postings and articles from peers are not permitted. 


"j" Only articles from peers are permitted; no articles are locally 
filed. 


"=other.group" Only articles from peers are permitted, and are filed 
under the newsgroup named "other.group". 


The server SHOULD use these values when these meanings are required 
and MUST NOT use them with any other meaning. 


A newsgroup with status "x" is a newsgroup with status "n", except 
that articles from peers are not accepted. A newsgroup with status 
"x" is considered as closed: no new articles will arrive in such a 
group. On the contrary, articles from peers will arrive ina 
newsgroup with status "n". Local postings are not allowed in a 
newsgroup with either of these two status field values. 


A newsgroup with status "j" is a newsgroup with status "y", except 
that (1) local postings are not accepted, (2) articles received from 
a peer that are crossposted to one or more valid groups are filed 
only into those valid groups, and (3) articles received from a peer 
that are not crossposted to any valid groups are not filed into any 
newsgroup, but are still propagated to other peers, if appropriate. 


NOTE: Instead of not filing at all an article posted to a 
newsgroup with status "j", a news server MAY file it under a 
catch-all group if no valid group is applicable. When a news 
server uses a catch-all group to file the articles posted to 
newsgroups with status "j", this catch-all group SHOULD be named 
"junk". (The first letter of the "junk" newsgroup explains why 
this status has been called "j".) 


Consequently, when a news server carries the "junk" newsgroup and 
uses it for the purpose of the "j" status, the "junk" newsgroup 
contains all postings not filed under another newsgroup, 
regardless of the status of the "junk" newsgroup. (However, an 
article posted explicitly to "junk" is treated according to the 
status of the "junk" newsgroup.) 


The "junk" newsgroup may be available to news readers and is often 
used by a news server as a way to locally store an article that 
will be transmitted to peers (which may carry some of the 
newsgroups the article was posted to even if the local server does 
not). In addition, instead of rejecting an article that contains 
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an invalid Newsgroups header field or that is posted to newsgroups 
it does not carry, a news server may accept such an article and 
file it under the catch-all newsgroup. 


Depending on the configuration of the news server, mentioning a 
newsgroup with status "j" is different than simply not listing the 
group, since articles arriving for unknown newsgroups may be 
rejected. 


When the status field value begins with an equal sign ("=" or %x3D), 
a newsgroup name on the news server MUST immediately follow the sign. 
If the status of "foo.bar" is "=other.group", it means that "foo.bar" 
is an alias for "other.group". These two newsgroups are distinct; 
they do not share their articles or their article numbers. Local 
postings to "foo.bar" are not allowed, but articles from peers are 
accepted for "foo.bar" and filed into "other.group", regardless of 
the status of "other.group". The contents of their Newsgroups header 
fields MUST NOT be altered. 


Alias groups are typically used during a transition between two 
newsgroups, including but not limited to a renaming of a group, or a 
correction of a misspelled group name. 


The status of the newsgroup an alias points to MUST NOT be taken into 
account when an article arrives in an alias newsgroup. In 
particular, it means that unapproved articles arriving from peers in 
an alias pointing to a moderated newsgroup are accepted and filed 
into this moderated newsgroup. Therefore, an alias SHOULD NOT point 
to a moderated newsgroup, since it allows bypassing of the 
moderation. 


An alias SHOULD NOT point to itself or another alias group. The 
newsgroup an alias points to SHOULD exist on the news server, and be 
visible to any client that can see the original group. However, when 
a client issues a LIST ACTIVE command with a wildmat including the 
original group, the newsgroup it points to is not listed in the 
response (unless of course the second newsgroup also matches the 
wildmat). 


NOTE: If a server files newsgroups with status "j" into "junk", a 
newsgroup with status "j" and a newsgroup with status "=junk" are 
different. An article fed by a peer, and crossposted to a group 
with status "j", will result in the article being filed only in 
"Junk" if there are no other groups with which to file it, or 
otherwise only in other valid newsgroups it is crossposted to. On 
the other hand, an article fed by a peer, and crossposted to a 
group with status "=junk", will result in the article being filed 
in "junk" and in other valid newsgroups it is crossposted to. 
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The following table summarizes what usually happens to an article 
posted to only the newsgroup "foo.bar", depending on its status field 
value on the news server: 


+--------------- 4------------ +----------- t------------ 4------------- + 
| Status field | Accepted | Accepted | Moderation | Destination | 
| value of | if local | from | needed? | if accepted | 
| “foe. bar" | posting? | peers? | | 

tesen Sietse a t----------- t------------ 4-—----------- + 
| y | Yes | Yes | No | foo.bar 

| n | No | Yes | No | foo.bar 

| m | Yes | Yes | Yes | foo.bar 

| x | No | No | No | 

|j | No | Yes | No | junk (if | 
| | | | | filed) | 
| =other.group | No | Yes | No | other.group | 
+--------------- +------------ +----------- 4------------ A n E + 


The following table summarizes what usually happens to an article 
crossposted to the newsgroup "foo.bar" and a valid newsgroup 
"misc.test" (whose status field is "y") known by the news server, 
depending on the status field value of "foo.bar" on the news server: 


4--------------- +----------- +----------- P A t-------------- + 
| Status field | Accepted | Accepted | Moderation | Destination | 
| value of | if local | from | needed? | if accepted | 
| "foo .bar" | posting? | peers? | | 
+--------------- E A Toere 4------------ t-------------- + 
| y | Yes | Yes | No | foo.bar, 
| | | | | misc.test | 
Es | No | Yes | No | foo.bar, 
| | | | | misc.test | 
| m | Yes | Yes | Yes | foo.bar, 
misc.test 

x No Yes No misc.test 
l5 | No | Yes | No | misc.test 
| =other.group | No | Yes | No | other.group, | 
| | | | | misc.test | 
+--------------- phn nn A AE t------------ a === + 


NOTE: The status of a newsgroup only indicates how articles 
arriving for that newsgroup are normally processed; news servers 
MAY provide clients with special privileges to allow or disallow 
some rights in these newsgroups. This specification defines 
neither these rights nor whether or not articles posted to these 
groups should be propagated to other peers. 
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3.2. Examples 


Example of an article posted to an alias group by a peer: 


[C] 
[S] 
[S] 
[S] 
[S] 
[C] 
[S] 
[C] 
[C] 
[C] 
[C] 
[C] 
[C] 
[C] 
[C] 
[C] 
[C] 
[C] 
[S] 
[C] 
[S] 
[S] 
[S] 
[S] 
[C] 
[S] 
[S] 
[S] 
[C] 
[S] 
[S] 
[S] 


LIST ACTIVE 

215 List of newsgroups follows 
foo.bar 21 12 y 

misc.test 3002322 3000234 =foo.bar 


IHAVE <for.misc.test@example.com> 

335 Send it; end with <CR-LF>.<CR-LF> 
Path: demo! .POSTED.somewhere!not-—for-mail 
From: "Demo User" <nobody@example.com> 
Newsgroups: misc.test 

Subject: I am just a test article 

Date: 18 Oct 2008 16:02:45 +0200 
Organization: An example, Paris, FR. 
Message-ID: <for.misc.test@example.com> 
MIME-Version: 1.0 


This is just a test article. 


235 Article transferred OK 

LIST ACTIVE 

215 List of newsgroups follows 
foo.bar 22 12 y 

misc.test 3002322 3000234 =foo.bar 


HDR Xref <for.misc.test@example.com> 
225 Header information follows 
0 news.example.com foo.bar:22 


HDR Newsgroups <for.misc.test@example.com> 
225 Header information follows 
0 misc.test 


The Newsgroups header field of this article is kept untouched. T 
article is filed under "foo.bar" even though it has originally be 
posted to the newsgroup "misc.test". Yet, it still propagates to 
peers that have been configured to receive articles posted to 
"misc.text". 
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Example of an article locally posted to an alias group: 


[C] LIST ACTIVE 

[S] 215 List of newsgroups follows 

[S] foo.bar 22 12 y 

[S] misc.test 3002322 3000234 =foo.bar 

[SJ]. 4 

[C] POST 

[S] 340 Input article; end with <CR-LF>.<CR-LF> 
[C] From: "Demo User" <nobody@example.com> 

[C] Newsgroups: misc.test 

[C] Subject: I am just a test article 

[C] MIME-Version: 1.0 

[C] 

[C] This is just a test article. 

EG}. 4 

[S] 441 Newsgroup "misc.test" has been renamed to "foo.bar" 


The article is rejected, with a detailed error. 

4. Augmented BNF Syntax for These Additions to the LIST Command 
This section describes the formal syntax of the new LIST variants 
defined in this document using [RFC5234]. It extends the syntax in 
Section 9 of [RFC3977], and non-terminals not defined in this 
document are defined there. The [RFC3977] ABNF should be imported 
first, before attempting to validate these rules. 


4.1. Commands 


This syntax extends the non-terminal <list-arguments>, which 
represents the variants of the LIST command. 


; counts 
list-arguments =/ "COUNTS" [WS wildmat] 


; distributions, moderators, motd 
list-arguments =/ "DISTRIBUTIONS" / "MODERATORS" / "MOTD" 


; subscriptions 
list-arguments =/ "SUBSCRIPTIONS" [WS wildmat] 


4.2. Responses 
This syntax extends the non-terminals <newsgroup-status> and 
<list-content>, which represent the status field value returned by 


the LIST ACTIVE command and the response contents for the LIST 
command, respectively. 
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; active 
newsgroup-status =/ newsgroup-alias / 
x78 / Sx6a ; case-sensitive "x" and "j" 
newsgroup-alias = "=" newsgroup-name 
; counts 


list-content =/ list-counts-content 
list-counts-content = 
* (newsgroup-name 3(SPA article-number) 
SPA newsgroup-status CRLF) 


; distributions 
list-content =/ list-distributions-content 
list-distributions-content = 

* (distribution WS distribution-description CRLF) 
distribution-description = U-TEXT 


; moderators 
list-content =/ list-moderators-content 
list-moderators-content = 

*(wildmat ":" moderators-address CRLF) 
moderators-—address = S-TEXT 


; motd 
list-content =/ list-motd-content 
list-motd-content = *(*U-CHAR CRLF) 


; subscriptions 
list-content =/ list-subscriptions-content 
list-subscriptions-content = *(newsgroup-name CRLF) 
5. Internationalization Considerations 
No new internationalization considerations are introduced by this 
extension, beyond those already described in the core specification 


[RFC3977]. 


In particular, newsgroup names SHOULD be restricted to US-ASCII 
[ASCII] until a successor to [RFC5536] standardizes another approach. 


Distribution descriptions and the message of the day MUST be in UTF-8 
[RFC3629]. 
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6. Security Considerations 


No new security considerations are introduced by this extension, 
beyond those already described in the core specification [RFC3977] 
and the Netnews Architecture and Protocols specification [RFC5537] 
(especially distribution leakage and e-mail Denial of Service during 
the moderation process). 


7. IANA Considerations 
This section gives a formal definition of this extension as required 
by Section 3.3.3 of [RFC3977] for the IANA registry. It extends the 
LIST capability label defined in Section 7.6 of [RFC3977]. 


o This extension provides additional keywords to the pre-existing 


LIST capability defined in Section 7.6 of [RFC3977]. New status 
field values are also added to the ACTIVE variant of the LIST 
command. 


o The capability label that this extension extends is "LIST". 


o This extension adds five optional arguments to the "LIST" 
capability label: "COUNTS", "DISTRIBUTIONS", "MODERATORS", "MOTD", 
and "SUBSCRIPTIONS", indicating which new variants of the LIST 
command are supported. Consequently, this extension associates 
these new arguments with the pre-existing "LIST" NNTP command. 


o This extension defines five new commands, LIST COUNTS, LIST 
DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS, 
whose behavior, arguments, and responses are defined in 
Sections 2.2, 2.3, 2.4, 2.5, and 2.6, respectively. 


o This extension does not associate any new responses with pre- 
existing NNTP commands. 


o This extension does not affect the maximum length of commands or 
initial response lines. 


o This extension does not alter pipelining. The LIST COUNTS, LIST 
DISTRIBUTIONS, LIST MODERATORS, LIST MOTD, and LIST SUBSCRIPTIONS 
commands can be pipelined. 


o Use of this extension does not alter the capabilities list. 


o This extension does not cause any pre-existing command to produce 
a 401, 480, or 483 response. 
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9. 


9. 


le 


o This extension is unaffected by any use of the MODE READER 
command. 


o This extension does not affect the overall behavior of a server or 
client other than via the new commands. 


o Published Specification: This document. 
o Contact for Further Information: Author of this document. 
o Change Controller: IESG <iesg@ietf.org>. 
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